1. Field of the Invention
The present invention relates generally to the field of data distribution and storage, and more particularly to a method for synchronizing data on a mobile device with data stored in a centralized location.
2. Description of the Prior Art
In networked computer systems data is commonly stored in a central location such as a collection of disk drives. In networked computer systems such as those commonly found in business offices, a network server includes a primary data storage system for the network, and the networked computers access files and other data from the network server to cache locally. Increasingly, mobile devices such as laptop computers, handheld computers, and Personal Digital Assistants (PDAs) are being linked to networked computer systems.
FIG. 1 illustrates a simplified networked computer system 10 including a central database 12 and three connected devices, a Personal Digital Assistant (PDA) 14, a laptop computer 16, and a desktop computer 18. The devices are connected to the network by connections 20 that may take several forms. A connection 20 can be permanent, as in the case of the desktop computer 18 or the laptop computer 16 when it is attached to a docking station. A connection 20 can also be temporary, as in the laptop computer 16 when connected to the central database 12 over a dial-up Internet connection, or the PDA 14 when using an infra-red signal to communicate with a networked computer. A connection 20 may also be made between any of these devices and the central database 12 by way of a wireless modem. In FIG. 1 the PDA 14 and the laptop computer 16 are operated by User A while the desktop computer 18 is operated by User B. It will be understood from FIG. 1 that any number of permanent and mobile devices can be networked to the networked computer system 10 and that each user can be identified with more than one device.
In order to take full advantage of the networked computer system 10, its applications, and its extensive storage capacity, a mobile device will necessarily include a data storage system that should be regularly synchronized with the central database 12 to keep the data on the mobile device current. Ideally, the synchronization process should be able to provided the mobile device with a subset of the data residing in the central database 12, where the subset is no larger than necessary to meet the needs of the device. Keeping the subset small is desirable because a mobile device typically has a storage capacity several orders of magnitude less than that of a central database 12, and will operate faster when unencumbered by large amounts of data. Further, the synchronization process should be able to efficiently sort the subset from what can often be a substantially greater amount of data within the central database 12. Additionally, the synchronization process should allow changes to the distribution rules to be readily implemented. Further still, the synchronization process should be able to operate regardless of whether the data structures in the central database 12 and the mobile device are the same or not. Lastly, the synchronization process should be able to recognize updates made to data on the mobile device and synchronize those updates to the central computer system.
FIG. 2 represents a typical data storage structure for related objects in a database, as may be used in a central database, according to the prior art. An object is a collection of data arranged in a particular manner, such as a table with rows and columns where each row represents a different record and each column entry contains the same attribute such as a date, a name, a value, etc. In FIG. 2 multiple object types 22, 24, and 26 are represented, where each object type 22, 24, and 26 is specific to a particular type of data record. As shown, multiple objects can exist of each object type. In a business context, for example, object types 22, 24, and 26 can include contact information for individuals, product information for companies, and sales records.
As shown in FIG. 2, each object type 22, 24, and 26 includes a primary key 28 that is a field dedicated to a unique identifier. For an object type that represents data about customers, the primary key 28 would be a unique customer number for each customer. Each object type 22, 24, and 26 also includes fields for data entries 29. For an object type that represents data about customers, for example, data entries 29 can include the number of years the customer has been a purchaser, the customer's field of business, and so forth.
Additional fields within an object type 22 and 24 can be used to relate different object types 22, 24, and 26 together. In FIG. 2 object type 22 includes a first foreign key 30 that links object type 22 to object type 24, and a second foreign key 32 that links object type 22 to object type 26. Similarly, object type 24 is also linked to object type 26 by the second foreign key 32. As can be seen from FIG. 2, an object type can include any number of foreign keys or no foreign keys. As with primary keys 28, a foreign key 30 and 32 is a field dedicated to a unique identifier in the target object type. Referring again to a business context, object type 22 may represent corporate clients, object type 24 may represent primary contact individuals, and object type 26 may represent street addresses. In this context foreign key 30 can be the primary key 28 for object type 24 and foreign key 32 can be the primary key 28 for object type 26. Accordingly, a record in object type 22 may provide information about XYZ Corporation including a street address for the corporate headquarters and the name of a primary contact person at XYZ Corporation. The field for the primary contact person would simply be foreign key 30, and the field for the street address would be foreign key 32. In the case where the primary contact person for XYZ Corporation has an office at the corporate headquarters, the particular street address record referenced by foreign key 32 will be the same, otherwise, the object type 22 record for XYZ Corporation will reference one address record of object type 26 while the object type 24 record for the primary contact will reference a second address record in object type 26.
Returning now to the issue of synchronization between a mobile device and a central database 12, several methods already exist to distribute data to a mobile device. Perhaps the oldest and most simplistic method is to run an extract program that contains a set of distribution rules. The extract program sequentially reviews every object in the central database 12 and if a particular object meets the distribution rules then the object is copied to a dataset that is later transferred to the mobile device. Since the extract program reviews every object in the central database 12, this method of synchronization becomes increasingly inefficient as the size of the central database 12 gets larger.
Another method for achieving a synchronization is to use a publish/subscribe mechanism. In this method a subscription list associates a mobile device with the entire set of object types that may be required by the mobile device. The distribution list may contain further rules to limit how many objects of any particular object type are actually published to the mobile device during the synchronization. In yet another method for achieving a synchronization a set of distribution rules are encapsulated within each object type. Here, when a mobile device requests an object type, the distribution rules are executed to determine which objects of that object type are actually provided.
As noted above, an additional issue for mobile devices is their limited storage capacities. Accordingly, it is desirable to store on a mobile device only a subset of the data available from the central database 12. Hammond (U.S. Pat. No. 5,758,337) discloses a solution where the same data structure, and hence the same object relationships, are maintained in both the central database 12 and the mobile device. In Hammond the object relationships are arranged in tables. The process of Hammond begins by generating on the mobile device an empty replica of the original database schema. Filters are then applied to the tables of the original central database to select desired rows and all related rows to partially populate the database replica. By maintaining referential integrity in this way, Hammond essentially requires that the same application be used to access the replicated database on the mobile device as was used to access the original database. Further, because object relationships are arranged in tables, computation-intensive table join operations are required to access object relationship information stored on the mobile device.
Accordingly, there is a need for a method to distribute data to a mobile device from a central database that is capable of efficiently identifying only that subset of data that is necessary to the mobile device. Further, the method should be independent of whether the database structures are the same in the central database and the mobile device. Further still, the method should preserve the object relationship information at the mobile device.